axios는 params 값으로 URLSearchParams 인스턴스도 받아용
중복되는 param는 바로 위 remote 함수와 같은 방식으로 넣을 수 없기에 사용했습니다~

중복되는 param는 바로 위 remote 함수와 같은 방식으로 넣을 수 없기에 사용했습니다~

💬 안되는건가요? 아래와 같은 방법으로 충분히 되는 것 같아요.

// 1 string
const params = new URLSearchParams(`keyword=${query}&type=singer&type=song`);

// 2 array
const params = new URLSearchParams([
  ['keyword', query],
  ['type', 'singer'],
  ['type', 'song'],
]);

바로 위에 있는 remote함수와 같은 방식으로 넣을 수 없어서 URLSearchParams 를 썻다~ 가 핵심입니다 ㅋㅋ
제시해주신 방법도 충분히 가능합니다 ㅋㅋ

클라이언트 베이식은 인터셉터를 달지 않은 인스턴스 입니다.
리프레쉬 remote 함수에만 사용됩니다.

리프레쉬 요청 함수에도 인터셉터를 부착한 인스턴스를 사용하는 경우,
응답 에러 인터셉터가 무한 호출됩니다.
이 경우 정상적으로 에러를 전파하기 위해 필요합니다.

💬 제가 이해한 게 맞나요? clientBasic 은 토큰 재발급 용도로만 사용되는 axios 인스턴스. 현재 인증 에러 시에 토큰을 재발급 받는 로직이 인터셉터로 주입하고 있지만, 토큰 재발급 요청 에러 시에는 재발급 요청을 반복해서 받을 필요가 없음. 그래서 토큰 재발급 요청에만 다른 인스턴스를 사용한다는 것.

토큰 재발급 요청 에러 시에는 재발급 요청을 반복해서 받을 필요가 없음.
이부분 만 다시 설명하자면, 정확히는

에러 인터셉터가 달려있는 인스턴스로 리패치 요청 + 이 요청에서 에러가 발생하면 다시 인터셉터에 걸림 + 또 요청
위 무한 굴레를 쫌 쉽게 처리하려고 만들었어요!

(다른방향으로 해결방법을 생각해보면, 카운터 변수를 하나 만들어서 리패치 요청의 횟수를 제한해도 되겠네용)

지금도 괜찮고, 다른 방향으로 제시한 것도 괜찮네요! 역시 도우밥!

401 에러이면서, 토큰을 가지고 있었을 때, 즉 사용자의 토큰이 만료되었을 때를 특정합니다.

401 에러 발생 시, 토큰을 가지고 있는 상황이라면 '토큰이 만료되었을 가능성'이 있다. 그러니 헤더에 토큰값이 있다면 재발급 요청을 보내라는 것이군요! 👍

프라미스의 특성을 이용한 로직입니다.
한 페이지에서 auth 정보가 필요한 api를 2개 이상 호출하는데 토큰이 만료된 경우, reissue api는 1회만 호출해야하고 나머지 요청들 모두 순차적으로 재시도 해야합니다.

위 로직으로 조금이라도 먼저 호출된 api가 최초 1회만 reissue 요청을 보내고 뒤이어 실행되는 다수의 api는 해당 프라미스의 이행을 기다리게 됩니다.
이후 micro task queue에 inqueue한 순서대로 자기 자신을 재시도합니다.

reissue는 한번만 하는 로직을 만들기 어려웠을텐데 고생 많으셨네요! 하나의 프로미스로 관리한다는 점 인상 깊었습니다. 👍

오호 예제를 만들어보니 이해가 되었네요.

let promise = null;

const reissue = () => {
  return new Promise((resolve) =>
    setTimeout(() => {
      console.log('promise');
      resolve('accessToken');
    }, 5000)
  );
};

const onExpired = async () => {
  const accessToken = await (promise ??= reissue());
  console.log(accessToken);
};

onExpired();
onExpired();
onExpired();
onExpired();

// reissue promise는 한 번만 이행되지만
// console.log(accessToken)은 여러번 실행되어서
// promise
// accessToken *4

💬 현재 해당 함수는 구현부에서 await 1번하고, 사용처에서 await를 1번 더 해요. 객체분해할당만 하는 것이기 때문에 함수 구현부 내부에서는 굳이 await를 하지 않아도 되지 않을까요?

말씀하신 부분이 잘 이해가 안되어서 그런데
promise가 이행된 후에만 새 변수에 할당이 가능하지 않나요?
구조분해할당만을 위한 함수 구현부 내부의 await가 없어도 된다는 말씀이 맞을까용?

구조분해할당만을 위한 함수 구현부 내부의 await가 없어도 된다는 말씀이 맞을까용?

이것은 이제 도밥이 판단해야 할 것 같아요! 정말 해당함수에서 구조분해할당을 해서 data를 가져와야 하는지요! 다만, 제가 말씀드리고 싶은 것은 그렇게 함으로써 async-await를 두 번 사용하게 된다는 점입니다!

아하 '구조분해 할당을 위해 await가 필요없다' 가 아니고,
'await + 구조분해 할당을 해서 가져와야 하는가~ 가' 주안점이었군요!

오 그럼 궁금한게 있는데, await가 2번 사용되면 단점이있나요?

@ukkodeveloper

바깥에서 data({ asccessToken })를 바로 쓰려면 data를 풀어내서 내보내야 됩니다.
그냥 내보내게 되면 response 객체이겠죠.

const { accessToken } = await getAccessToken(platform, code);

다만 async/await가 불편하다면 then이 붙은 promise를 내보내면 될 것 같네요.
둘의 차이는 어떨지 더 알아봐야 알 것 같은데, 똑똑한 여러분들이 알려주실거라 믿습니다 😄

export const getAccessToken = (platform: string, code: string) => {
  return client
    .get<AccessTokenRes>(`/login/${platform}`, {
      params: { code },
    })
    .then((response) => response.data);
};

💬 제가 이해한 게 맞나요? clientBasic 은 토큰 재발급 용도로만 사용되는 axios 인스턴스. 현재 인증 에러 시에 토큰을 재발급 받는 로직이 인터셉터로 주입하고 있지만, 토큰 재발급 요청 에러 시에는 재발급 요청을 반복해서 받을 필요가 없음. 그래서 토큰 재발급 요청에만 다른 인스턴스를 사용한다는 것.

401 에러 발생 시, 토큰을 가지고 있는 상황이라면 '토큰이 만료되었을 가능성'이 있다. 그러니 헤더에 토큰값이 있다면 재발급 요청을 보내라는 것이군요! 👍

reissue에서 에러를 throw하고 리액트 단에서 라우팅해야할 것 같아요! 이거는 예외처리 (에러 바운더리)하면서 고려해보죠! 그리고 alert 부분도 로직과 ui가 결합되어 있는데 이것도 예외처리하면서 풀어낼 수 있을 것 같아요.

맞아용. 저도 에러바운더리에서 해결하는 방법도 있다고 생각했어용.
실제로 깔끔하게 적용까지 하고 싶었는데... 에러 처리는 원래 코난하고 같이하기로 했던 부분이라, 에러바운더리 하나 만드는것도 조금 고민되더라고요. 그래서 기존 코드에서 에바 없이 해결했던 방법으로 그대로 구현해두었습니당.
(서비스 터지지만 않게요 ㅋㅋ)

에바 얼른 합시당 ! 으아아아아아아악!

ㅎㅎ 에바 고우고우

reissue 인터셉터 따로 모듈 분리하는 게 좋을 것 같아요. reissue에만 사용되는 변수인데 핵심 로직과 떨어져 있어서 계속 앞뒤로 왔다갔다하면서 읽게 되네요!

reissue에만 사용되는 변수인데 핵심 로직과 떨어져 있어서 계속 앞뒤로 왔다갔다하면서 읽게 되네요!

좋습니당~ 공감하는 부분이라 사용처와 가깝게 let 변수의 line을 변경했어용!(반영 완)

💬 다만, 인터셉터는 인스턴스에 부착하는 로직인 만큼 한 파일에 모아두는게 더 좋다고 생각하는데, 어떻게 생각하세용?

그냥 제 생각을 말할게요! ( 이렇게 해달라는 것은 아닙니다! 도밥이 생각하고 정리하면 좋을 것 같아요! )
우선 axios 인스턴스에 인터셉터를 주입하는 인터페이스를 보면 인자로 함수를 받잖아요. 이것만 봐도 요청 전후의 작업을 "독립적"으로 코드를 짤 수밖에 없도록 하는 느낌이 들거든요! "독립적"이라는 것은 별도로 분리해서 모듈화하거나 단위 테스트하거나 등등 장점(결국 관심사 분리를 통한 장점일 것 같네요)이 많잖아요. 그렇기 때문에 저는 분리하는 게 좋겠다는 생각이 들었어요!

별개로 만약 도밥이하나의 역할이라 결정 지었다면, reissuePromise 변수를 쓰는 함수 근처에 선언하는 게 더 좋을 것 같아요! 그래야위아래로 왔다갔다 안 하고 좋을 것 같습니다 👍

오호 좋은 접근법이네요.
인터페이스를 보고 생각하는 법 배워갑니다~! 야무진 인사이트 감사합니다.

이부분 설명해주실 수 있나요? 본 요청을 다시 보내는 로직인가요?

맞아용. axios는
client.get, client.post 형태의 인터페이스로 요청을 보낼 수도 있고
client(config객체) 형태의 인터페이스로도 요청을 보낼 수 있어용

기존 config객체에 토큰 받아온걸 set하고, 다시 요청 보내는 로직입니당
위 promise 사용처 설명처럼 순서대로 재요청해용~

와!우! 신기하네요! 정말 좋군요 axios~

reissue는 한번만 하는 로직을 만들기 어려웠을텐데 고생 많으셨네요! 하나의 프로미스로 관리한다는 점 인상 깊었습니다. 👍

💬 reissuePromise를 응답 에러 인터셉터에서만 관리하는 것이 어떠한가요? 두 함수 모두 해당 변수를 조작할 필요는 없을 것 같다는 생각이 드네요!

논리적으로
리프레시 완료 후 null할당 vs 토큰 갈아끼고 재시도 전 null 할당의 차이였는데
로직 상 문제가 없네요ㅎㅎ 구현 당시에 착각했었나 봅니다 하하
아주 좋은 의견 감사용 반영했습니당 👍

💬 prefer-const는 error가 아니라 warning인데 disable한 이유가 있으신가요

몰랐네요 ㅋㅋㅋㅋ 수정할게요~

💬 Res가 Response인가요?

네 맞아요 Res, Req!

💬 create는 CreateAxiosDefaults 타입을 받던데, AxiosRequestConfig 타입으로 선언한 이유가 있을까요?

export interface AxiosStatic extends AxiosInstance {
  create(config?: CreateAxiosDefaults): AxiosInstance;
  // ...
}

export interface CreateAxiosDefaults<D = any> extends Omit<AxiosRequestConfig<D>, 'headers'> {
  headers?: RawAxiosRequestHeaders | AxiosHeaders | Partial<HeadersDefaults>;
}

오호 감사합니다. 몰랐어요 ㅋㅋ..
내부적으로 headers 를 오밋해서 갈아끼네요. 원래 의도대로 쓰는게 좋겠어요.
수정완!

💬 제네릭이 필요 없어졌다면 useFetch도 수정해야되지 않을까요?

어떤 식으로 수정이 되어야할까요? 생각나는 방향이 있으시면 같이 알려주세용
제네릭 없이도 useFetch data 타입이 추론 될지 모르겠네용

💬 async/await여야 하는 이유가 있나요?

useMutaion의 타입을 맞추려다보니 그렇습니다~
useMutaion의 타입을 어떻게 수정해볼 수 있을까요?

💬 mutation 함수를 확인해보니 타입이 (...params: P) => Promise<T>인데, promise를 반환 안해도 되는건가요?

export const useMutation = <T, P extends any[]>(mutateFn: (...params: P) => Promise<T>) => {
  const [data, setData] = useState<T | null>(null);
  const [isLoading, setIsLoading] = useState(false);
  // ...

@ukkodeveloper

바깥에서 data({ asccessToken })를 바로 쓰려면 data를 풀어내서 내보내야 됩니다.
그냥 내보내게 되면 response 객체이겠죠.

const { accessToken } = await getAccessToken(platform, code);

다만 async/await가 불편하다면 then이 붙은 promise를 내보내면 될 것 같네요.
둘의 차이는 어떨지 더 알아봐야 알 것 같은데, 똑똑한 여러분들이 알려주실거라 믿습니다 😄

export const getAccessToken = (platform: string, code: string) => {
  return client
    .get<AccessTokenRes>(`/login/${platform}`, {
      params: { code },
    })
    .then((response) => response.data);
};

중복되는 param는 바로 위 remote 함수와 같은 방식으로 넣을 수 없기에 사용했습니다~

💬 안되는건가요? 아래와 같은 방법으로 충분히 되는 것 같아요.

// 1 string
const params = new URLSearchParams(`keyword=${query}&type=singer&type=song`);

// 2 array
const params = new URLSearchParams([
  ['keyword', query],
  ['type', 'singer'],
  ['type', 'song'],
]);

오호 예제를 만들어보니 이해가 되었네요.

let promise = null;

const reissue = () => {
  return new Promise((resolve) =>
    setTimeout(() => {
      console.log('promise');
      resolve('accessToken');
    }, 5000)
  );
};

const onExpired = async () => {
  const accessToken = await (promise ??= reissue());
  console.log(accessToken);
};

onExpired();
onExpired();
onExpired();
onExpired();

// reissue promise는 한 번만 이행되지만
// console.log(accessToken)은 여러번 실행되어서
// promise
// accessToken *4